【AWS】Stack is not required! CloudFormation支援ツール “kumogata” を試してみました

植木和樹

2014.07.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは植木和樹です。6月のJAWS-UG長野でcloudpackの山口さんが紹介されていたkumogataを試してみました。

内部でCloudFormationを使いながらも「テンプレートにコメントが記述できる」だけでうれしいkumogataですが、果たしてどのようなものなのでしょうか。

用意するもの

今回は手元のOSXにインストールしてみます。rubyはrbenvを入れて 1.9.3を使用しています。kumogataはgemコマンドで簡単にインストールができます。

% gem search kumogata -r
kumogata (0.4.17)

% gem install kumogata --no-rdoc --no-ri
Fetching: aws_config-0.0.2.gem (100%)
Fetching: diffy-3.0.5.gem (100%)
Fetching: dslh-0.2.6.gem (100%)
Fetching: kumogata-0.4.17.gem (100%)
Successfully installed aws_config-0.0.2
Successfully installed diffy-3.0.5
Successfully installed dslh-0.2.6
Successfully installed kumogata-0.4.17
4 gems installed

インストールができました。コマンドを実行してみましょう。

% kumogata --version
kumogata 0.4.17

CloudFormation JSONテンプレートからkumogataテンプレートに変換する

いきなりRubyでkumogataテンプレートを作成するのは敷居が高いので、既存のCloudFormationテンプレートを変換してみましょう。使ったのは定番のVPCクラメソ社内テンプレート。ページ内のリンクからgistにある"vpc-knowhow-2014-04.template"をダウンロードします。

【AWS】VPC環境構築ノウハウ社内資料 2014年4月版｜ Developers.IO

作業ディレクトリを作成し、ダウンロードしたテンプレートを配置しておきましょう。

% mkdir kumogata
% cd kumogata
% git init .
Initialized empty Git repository in /Users/uekikazuki/Desktop/kumogata/.git/
% mv ~/Downloads/vpc-knowhow-2014-04.template .

kumogataのconvertコマンドを使ってテンプレートを変換します。

% kumogata convert vpc-knowhow-2014-04.template
[ERROR] Invalid profile sectioning

おっといきなりエラーになりました。どうやらkumogataが内部で使っているaws_configライブラリ（0.0.2）が、$HOME/.aws/configの[preview]セクション（aws-cliで実験的機能を利用可能にする）をうまく扱えないようです。[preview]セクションを（#で）コメントアウトすればエラーが回避できます。

では、あらためて。変換されたテンプレートは標準出力に表示されるので適当なファイルにリダイレクトしておきましょう。

% kumogata convert vpc-knowhow-2014-04.template > vpc-knowhow-2014-04.rb

無事変換されたようなので、validateコマンドで構文チェックをしておきましょう。

% kumogata validate vpc-knowhow-2014-04.rb
[ERROR] undefined local variable or method `httpd' for #<Dslh::Scope:0x007fd1ab335688>
  from vpc-knowhow-2014-04.rb:1137:in `block (7 levels) in eval'

再度エラーになりました。1137行目の"httpd"がおかしいようです。

      AWS__CloudFormation__Init do
        config do
          packages do
            yum do
              httpd.
              mysql55.
            end
          end

cfn-initのpackagesの構文がおかしいようですね。Kumogata+CloudInit+cfn-init - so whatを参考に書きなおしましょう。

      AWS__CloudFormation__Init do
        config do
          packages do
            yum({
              "httpd" => [],
              "mysql55" => []
            })
          end

再度構文チェックをしたところ問題ないようです。

% kumogata validate vpc-knowhow-2014-04.rb
Template validated successfully

AWS各種リソースの作成

できあがったテンプレートを使ってAWSの各種リソースを作成してみます。createコマンド実行時にスタック名を指定しない場合はリソース作成後にCloudFormationのスタックは削除してくれるようです。（すべてのリソースに "DeletionPolicy":"retain" が設定されます）

それではcreateを実行してみましょう。--result-logで画面の出力結果をJSONファイルにも保存しておきます。

% kumogata create \
  --result-log result.log \
  --parameters "DBPassword=mypassword,HostedZone=example.com,KeyName=ueki_keypair" \
  vpc-knowhow-2014-04.rb

スタックの作成には20分ほどかかります。

スタックの削除

kumogataでのリソース作成時にスタック名を指定しなかったので、スタック作成後ただちにスタック削除が行われます。

ここで三度問題が発生。スタック削除の様子をみているとEC2インスタンスやRoute53のレコードはretainされているのですが、RDSのインスタンスがdeleteされてしまっているようです。どうやら元々のJSONのテンプレート側で"DeletionPolicy"にsnapshotが設定されていたためにconvert時に引き継がれてしまい、スタック削除時にDeleteされてしまったようです。テンプレート変換後には不要なDeletionPolicyを取り除いておくようにしましょう。

テンプレート修正後、再度試行したところRDSインスタンスもちゃんと残りました。

まとめ

というわけでkumogataを試してみました。CloudFormationでVPCなどの標準的な基盤は作りたいけれど、その後のスタックは管理したくない、という用途にはいいのではないでしょうか。

ただし内部でCloudFormationを使っているので、クセはそのまま引き継がれるためCloudFormationっぽさはなくすことはできません。

SecurityGroup名が "kumogata-" から始まるランダムな長い文字列になってしまう。
ELBのDNS Nameが "kumogata-" から始まるランダムな・・・
RDSのParameterGroup名が "kumogata-" から始まる・・・
IAMのRole名が・・・

今回は試せませんでしたが、kumogataでは構成がほぼ同じ（AZが異なるだけなど）複数EC2インスタンスの作成を"Iteration"を使って簡便に書くことができるようです。またサンプルのテンプレートをみると"UserData"の記述がスッキリと書けたり、ポストコマンド（_post）を使ってスタック作成後にEC2にsshログインしたりすることもできるようです。

CloudFormationには興味があるけど、けどJSONはなぁ・・・というナウでヤングな方は試してみてはいかがでしょうか。

ナウなヤングにCloud Formationが流行ってほしい from Sugawara Genki